Statistics GUI Klonan, Oxyd The statistics GUI (electric network stats, production stats, etc.) is one of the GUIs that has been in the game for a very long time, and has had its functionality fleshed out reasonably over the years. It was not long ago when Twinsen added hovering and highlighting to the graphs. Given that, and the relatively short timeframe for 1.0 release, the update of the statistics GUI has really just been a style update, no new features or heavy logic rewriting. Oxyd has most of the work done, so we are happy to show some real in-game screenshots of how it looks: A notable change with the electric stats is that the Satisfaction/Production/Accumulator charge are next to each other in a single row, as opposed to each in a separate row. The label for the exact amount has also been moved to inside of the progress bar, which itself is much thicker. The production stats are pretty much the same functionality wise. One new button you might spot is the search button. However there are some problems with the search feature. As you can see, production and consumption frames have a different search box independent from each other. The main problem is when pressing CTRL+F to perform a regular search: How do we know which frame to open? Of course this could lead to different solutions like the use of a cycle for the focus of the search, in which the second time you press CTRL+F the other frame gets the focus. Or both of the search boxes open at the same time but only one gets the focus. Or only one frame gets the focus and the other one works only by pressing the button. But let's face it, these "solutions" are not solid at all and create inconsistency in the main design. To solve this issue we decided that the simplest way to go is the use of just one search box on the header of the panel. This new location works as a general feature for the entire panel. One single search gives you 2 results, one on each frame. This solution is used in the new character window -to come soon- making it consistent with the whole design of the GUI. You can also see we took this opportunity to integrate the Kill statistics in with the rest, instead of being its own window with its own hotkey. The Statistics GUIs will need a few tweaks and polishings here and there before it is ready for release, but unless something unexpected happens you can expect it coming out in a release soon.
Hello, the forecast today says it is going to be 36°C, I bought two fans to help us overcome the crisis, but it is still quite rough.
Hello, the bugfixing period boringly continues, we got down to 159 active bug reports, so in few weeks we should be finally down with this burden. But at least the graphics department has something new to show:
Crash site: First state Ernestas, V453000, Albert For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site. It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar. Here a proof of concept of the look: The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit. The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details. It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones. For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes. The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent. This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones. These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers. All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together. The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.
Hello, Pretty much half of the office has been sick in the past week, but that still hasn't stopped us from progressing in the development of your favourite pollution-generating game (though I have been playing some Cities skyline recently and there you can screw the nature around quite creatively as well).
Ok→Cancel versus Cancel→Ok (kovarex) A really strange debate started as a continuation of FFF-238. I insisted that the button order should obviously always be OK Cancel, as in any UI I see around. But little I knew, that this is actually specific to windows, and on Linux or macOS, the order is reversed: Eventually, we figured out, that we are not the first one trying to solve the problem. The solution we are now experimenting it sounds like a bad idea: "Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory". Which brings me to the load game dialog mockup:
Hello, When playing with trains, you tend to spend a lot of time building train stops. In my latest playtesting, I noticed a few annoyances and pain points, which we will go in to today, along with some other improvements for 2.0.
Hello, Today we will be looking at (and listening to!) many of the sound improvements we have been working on for 2.0.
The many lessons learned from testing the new tutorial We have already pointed out, that we are trying to make a new campaign (FFF-245), and part of it is the core beginning, the NPE/tutorial. The tutorial is one of the very critical parts of the game, as if the first 15 minutes of a game feels shitty, there is big chance that the player will not play any further. I had this experience in many games myself. So the challenge could be articulated like this: "The current tutorial is okay, but can we make it great?" The approach in the current tutorial is to feed the player with the basic knowledge of how to control the basics of the game (the first mission and the start of the second mission) in the fastest way possible. The player is even given descriptive info like this, to diminish the chance of not understanding how the basic entities work. After few steps in the 2nd level, the player can start exploring his first self-feeding loop (make iron to make more iron). The tools used to this is mainly: The message dialog that stops the game and explains the player various things. Minimization of the amount of things the player can interact with to absolute minimum, so he can't start doing other things before the basics are clear. The possible drawbacks: The constant interruptions can get really annoying (typically around 22 message dialogs before the player starts to play relatively freely in the 2nd level). The possibility, that the player will mindlessly follow the step-by step tasks without understanding it, so he can become really lost later on, and the tutorial basically wouldn't help him to understand things. So the question is: Can we make a tutorial that makes these problems go away?, and alternatively, How big are these problems actually? The current direction of the new tutorial attempt is to never use the message dialogs, so the player can learn the game more fluently, and to leave way more things to explore, as learning things yourself has a better chance of success than force-feeding generally. We made a few tests of the new approach with a few people, the main takeaway, is that nothing is for free, and this approach created new drawbacks. If the player doesn't figure out something basic, it can be very frustrating for him to figure out what is going on when not moving forward for a long time. It might be possible, that some things are just not fun to learn by exploration, and it is more comfortable if they are force fed to you. I would compare this to a friend explaining you how to play a game for 5 minutes compared to 2 hours of trial and error. There are more possible outcomes from this, and we shall see how different tweaks of both strategies work in the testings. It might be interesting if you mentioned your experience with the tutorial in the comment section as well.
